Rust: Associated types #19214
Rust: Associated types #19214
Conversation
paldepind
force-pushed
the
rust-ti-associated
branch
from
4d8454c to
77e1b23
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| println!("{:?}", x4); | ||
|
|
||
| let x5 = S2; | ||
| println!("{:?}", x5.m1()); // $ method=m1 MISSING: type=x5.m1():A.S2 |
There was a problem hiding this comment.
This missing type is probably worth fixing. But since it's not for a method in a trait block and not a regression I didn't look into it for this PR.
There was a problem hiding this comment.
This got fixed when I merged main. Did you do something to fix this @hvitved? 😁
There was a problem hiding this comment.
Wouldn't that be your very own #19146? :-) Because now the Self::AssociatedType return type of m1 inside impl MyTrait for S2 can resolve to Wrapper<S2>
| @@ -15,6 +16,7 @@ newtype TType = | |||
| TArrayType() or // todo: add size? | |||
| TRefType() or // todo: add mut? | |||
| TTypeParamTypeParameter(TypeParam t) or | |||
| TAssociatedTypeTypeParameter(TypeAlias t) { any(TraitItemNode trait).getADescendant() = t } or | |||
There was a problem hiding this comment.
I have a slight preference for getAnAssocItem over getADescendant, but it should do that same.
| @@ -320,6 +333,55 @@ class TypeParamTypeParameter extends TypeParameter, TTypeParamTypeParameter { | |||
| } | |||
| } | |||
|
|
|||
| /** Gets type alias that is the `i`th type parameter of `trait`. */ | |||
There was a problem hiding this comment.
Gets type -> Gets the type.
There was a problem hiding this comment.
Perhaps add a comment that type aliases are numbered arbitrarily but consecutively, starting from the index following the last ordinary type parameter.
| * // ... | ||
| * } | ||
| * ``` | ||
| * is treated as if it where |
| TypeAlias getTypeAlias() { result = typeAlias } | ||
|
|
||
| /** Gets the trait that contains this associated type declaration. */ | ||
| TraitItemNode getTrait() { result.getADescendant() = typeAlias } |
There was a problem hiding this comment.
Again, I prefer getAnAssocItem.
| /** Gets the trait that contains this associated type declaration. */ | ||
| TraitItemNode getTrait() { result.getADescendant() = typeAlias } | ||
|
|
||
| int getIndex() { traitAliasIndex(this.getTrait(), result, typeAlias) } |
| exists(ImplItemNode impl, AssociatedTypeTypeParameter param, TypeAlias alias | | ||
| this = impl.getTraitPath() and | ||
| param.getTrait() = resolvePath(this) and | ||
| alias = impl.getASuccessor(param.getTypeAlias().getName().getText()) and | ||
| result = alias.getTypeRepr() and | ||
| param.getIndex() = i | ||
| ) |
There was a problem hiding this comment.
It took me a while to see why type arguments are not mixed up when a trait has multiple associated types. It would be a nice to have a test for that.
| @@ -106,6 +131,13 @@ class TypeParamMention extends TypeMention, TypeParam { | |||
| override Type resolveType() { result = TTypeParamTypeParameter(this) } | |||
| } | |||
|
|
|||
| // Used to represent implicit associated type type arguments in traits. | |||
There was a problem hiding this comment.
It's not the easiest thing to read but the repeated type is intentional as it's supposed to be "associated type" type arguments. I've reworded it so that the two "type"s don't occur back-to-back.
| override TypeReprMention getTypeArgument(int i) { none() } | ||
|
|
||
| override Type resolveType() { result = TAssociatedTypeTypeParameter(this) } |
There was a problem hiding this comment.
Not all TypeAliases should be type mentions, so perhaps
private Type t;
TypeAliasMention() { t = TAssociatedTypeTypeParameter(this) }
override TypeReprMention getTypeArgument(int i) { none() }
override Type resolveType() { result = t }
This PR improves calls to methods in
traitblocks (not methods inimplblocks) that refer to associated types.One approach to implementing this would be: When a method call resolves to a method inside a trait we find the
implblock that makes theselfargument implement the trait. Thisimplblock contains the definition of the associated type, and when we read off the declared type of the method we convert the associated type to the specific definition of the type.However, this change would have to be done inside
getDeclaredTypewhich right now doesn't depend on the call site at all. Hence, instead of doing that, this PR handles associated types by treating them as type parameters. I.e. a trait like this:is treated as-if it was
One downside of this approach is that it's not immediately clear to me how to handle associated types with generics like this:
Here
Self::GenericAssociatedTyperefers to a type parameter ofput. So what should we do for theApassed to it?TheGenericAssociatedTypetype parameter would have to be handled as a sort of higher-kinded type.My impression is that associated types with generics is a feature that is not used very much. So I suggest that it's ok to not handle that feature, unless there's some straightforward way to do it.